• Remove the in-repo tenant-release ServiceAccount in favor of Konflux-managed konflux-bot-0.
• Rename release Role/RoleBinding to conforma-release and re-target binding to konflux-bot-0.
• Document required registry push secrets that must be attached to konflux-bot-0 in-cluster.

graph TD
  A["release/setup.yaml"] --> B["Role (conforma-release)"] --> C["RoleBinding (conforma-release)"] --> D["ServiceAccount: konflux-bot-0"] --> E[("Registry push secrets")]
  D --> F["Release pipelines"]
  G{{"Konflux
(pre-creates SA)"}} --> D

  subgraph Legend
    direction LR
    _cfg["Config/Manifest"] ~~~ _rbac["RBAC"] ~~~ _sa["ServiceAccount"] ~~~ _sec[("Secret")] ~~~ _ext{{"External system"}}
  end

Loading

The following are alternative approaches to this PR:

1. Request a dedicated Konflux-managed bot SA for releases

• ➕ Keeps a distinct identity for release automation (least privilege, clearer audit trails).
• ➕ Avoids coupling multiple use-cases to the shared konflux-bot-0 identity.
• ➖ Requires platform/cluster coordination and lead time; may miss the policy deadline.
• ➖ Still relies on Konflux conventions and cluster-side setup.

2. Keep `tenant-release` SA but enforce policy via admission/labels

• ➕ Maintains existing RBAC wiring and SA identity with minimal downstream changes.
• ➖ Conflicts with the stated Konflux SA security policy (likely rejected by enforcement).
• ➖ Does not remove the operational burden of managing SA lifecycle and secrets in-repo.

Recommendation: Proceed with this PR’s approach: binding RBAC to the pre-created konflux-bot-0 aligns with the stated Konflux policy and minimizes in-repo identity management. Ensure the dependent ReleasePlan serviceAccountName change is merged first and validate that ec-cli-main and ec-tekton-task-main are attached to konflux-bot-0 in the target cluster before relying on the new binding.

Other (1) +13 / -17

setup.yamlRebind release RBAC from tenant-release SA to konflux-bot-0 +13/-17

Rebind release RBAC from tenant-release SA to konflux-bot-0

• Removes the repo-defined 'tenant-release' ServiceAccount and replaces it with documentation indicating 'konflux-bot-0' is pre-created by Konflux. Renames the Role/RoleBinding to 'conforma-release' and updates the RoleBinding subject to 'konflux-bot-0' while keeping the same roleRef semantics.

release/setup.yaml

Walkthrough

The release setup manifest now documents and binds the pre-created konflux-bot-0 ServiceAccount instead of declaring tenant-release. The README setup instructions were updated to match the new release pipeline account setup.

Changes

Release pipeline account update

Estimated code review effort: 1 (Trivial) | ~3 minutes

Related PRs: None identified.

Suggested labels: release, configuration

Suggested reviewers: None identified.

Poem

A bunny hopped through YAML fields so neat,
Swapped one old account for one pre-built and sweet,
konflux-bot-0 now holds the key,
With docs and RBAC in harmony,
A tiny hop, a tidy feat! 🐇

Description

release/README.md still claims setup.yaml "creates a ServiceAccount", but the PR removes the
ServiceAccount manifest and instead assumes an externally pre-created konflux-bot-0 SA, which will
mislead operators following the setup docs.

Code

release/setup.yaml[R18-26]

+# The konflux-bot-0 ServiceAccount is pre-created by Konflux. The secrets
+# and role binding below grant it push access to the release registries
+# and read access to release resources.
+#
+# The following secrets must be attached to konflux-bot-0 in the cluster:
+#   - ec-cli-main: push credential for quay.io/conforma/cli
+#     and quay.io/enterprise-contract/cli
+#   - ec-tekton-task-main: push credential for quay.io/conforma/tekton-task
+#     and quay.io/enterprise-contract/tekton-task

Relevance

⭐⭐⭐ High

Team historically updates docs when behavior/config changes (see docs alignment PRs 2600, 3093).

PR-#2600
PR-#3093

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The README explicitly says applying setup.yaml creates a ServiceAccount, while
release/setup.yaml now documents that konflux-bot-0 is pre-created and contains no
ServiceAccount object definition.

release/README.md[6-10]
release/setup.yaml[18-26]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The release setup documentation no longer matches what `release/setup.yaml` actually creates after migrating to `konflux-bot-0`.

### Issue Context
`release/setup.yaml` now only defines RBAC and comments about required secrets, and does not create a ServiceAccount.

### Fix Focus Areas
- release/README.md[6-10]
- release/setup.yaml[18-26]

### Suggested fix
Update `release/README.md` to state that `setup.yaml` creates the Role/RoleBinding for the pre-created `konflux-bot-0` ServiceAccount and that the listed secrets must already be attached to `konflux-bot-0` in the cluster.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

release/setup.yaml now contains an initial YAML document consisting only of comments (started by a
leading --- and ended by the next ---), which can deserialize to an empty object and fail in
apply flows that expect apiVersion/kind per document.

Code

release/setup.yaml[R18-27]

+# The konflux-bot-0 ServiceAccount is pre-created by Konflux. The secrets
+# and role binding below grant it push access to the release registries
+# and read access to release resources.
+#
+# The following secrets must be attached to konflux-bot-0 in the cluster:
+#   - ec-cli-main: push credential for quay.io/conforma/cli
+#     and quay.io/enterprise-contract/cli
+#   - ec-tekton-task-main: push credential for quay.io/conforma/tekton-task
+#     and quay.io/enterprise-contract/tekton-task
---

Relevance

⭐⭐ Medium

No prior repo review history found about rejecting/accepting empty YAML documents with leading '---'
comments.

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The file begins with a --- and does not define any Kubernetes object until after a second ---,
meaning the first document contains only comments. The repo’s YAML apply helper unmarshals each
document into an Unstructured and then resolves a REST mapping from its GVK; an empty document has
no GVK and will fail that mapping step.

release/setup.yaml[1-28]
acceptance/kubernetes/kind/kind.go[331-351]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`release/setup.yaml` currently has two YAML document separators (`---`) with only comments in between, which creates an empty first YAML document. Some YAML consumers (including this repo’s apply helper) unmarshal each document and immediately use its GVK; empty docs will produce an object with no GVK and can error.

### Issue Context
This was introduced when the `ServiceAccount` manifest was removed but the original document structure (`---` separators) remained.

### Fix Focus Areas
- release/setup.yaml[1-28]

### Suggested fix
Remove the leading `---` at the very top of `release/setup.yaml` (or alternatively remove the separator at current line ~27) so the first YAML document contains a real Kubernetes object (Role) rather than only comments.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

Renaming the Role/RoleBinding from tenant-release to conforma-release means existing clusters
that previously applied this file will keep the old tenant-release Role/RoleBinding unless they
explicitly prune/delete them, leaving stale privileges behind.

Code

release/setup.yaml[R48-55]

+  name: conforma-release
  namespace: rhtap-contract-tenant
subjects:
  - kind: ServiceAccount
-    name: tenant-release
+    name: konflux-bot-0
roleRef:
  kind: Role
-  name: tenant-release
+  name: conforma-release

Relevance

⭐⭐ Medium

No historical evidence found on renamed K8s RBAC resources leaving stale objects in apply-only
flows.

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The PR changes object names in release/setup.yaml, which causes new objects to be created rather
than updating existing ones with the old names. The repository’s apply helper demonstrates an
apply-only strategy (no deletion/pruning), so old objects would persist unless removed out-of-band.

release/setup.yaml[28-56]
acceptance/kubernetes/kind/kind.go[360-378]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
Clusters that previously applied the old `tenant-release` RBAC will not automatically delete it when applying the new manifest, because apply flows update/create only the objects present in the YAML.

### Issue Context
This repo contains apply logic that uses server-side Apply per object and does not prune resources removed from manifests. Since the PR renames objects, the old ones will remain unless explicitly deleted.

### Fix Focus Areas
- release/README.md[6-10]
- acceptance/kubernetes/kind/kind.go[360-378]
- release/setup.yaml[28-56]

### Suggested fix
Document a migration step in `release/README.md` (or add a small `release/cleanup.yaml` plus instructions) to delete the legacy objects:
- `ServiceAccount/tenant-release`
- `Role/tenant-release`
- `RoleBinding/tenant-release`

Also mention that a prune-capable GitOps sync is required if relying on automated deletion.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.